home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 800 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.4 KB
  1. Date: Thu, 13 Jan 1994 13:26:23 +0100
  2. From: Christian Lynbech <lynbech@daimi.aau.dk>
  3. Message-Id: <199401131226.AA12497@avignon.daimi.aau.dk>
  4. To: entropy@terminator.rs.itd.umich.edu
  5. In-Reply-To: <199401130207.VAA14533@terminator.rs.itd.umich.edu> (entropy@terminator.rs.itd.umich.edu)
  6. Subject: Re: [MINTOS] compiler switch (was: Re: MiNT goes UNiX, ...)
  7.  
  8. > Since the whole point of the mint library is to provide a UNIX-like
  9. > environment, the __MINT__ flag should be interpreted as "MiNT running
  10. > on a UNIX-like system", e.g. you shouldn't mangle pathnames and so on.
  11.  
  12. It depends on whether this is generally perceived as the true purpose
  13. of MiNT and/or the library.
  14.  
  15. Some people may think of MiNT as providing a general multiprocess
  16. TOS/GEMDOS extension, rather as an UNIX-like OS. I'm not sure how easy
  17. it is to separate the mintlib from such perceptions, as the mintlib is
  18. *the* way for C programmers to interact with MiNT.
  19.  
  20. > If you want to make it possible for people to compile your code in
  21. > such a way that it works on plain TOSFS, I'd reccommend the following:
  22. > 
  23. > #ifdef __atarist__
  24. > #ifndef __MINT__
  25. > #define TOSFS
  26. > #endif
  27. > #endif
  28.  
  29. I think this is a brilliant solution, provided that we can get
  30. everyone to agree on this interpretation of __MINT__. Actually it
  31. probably is no problem at all. Most people interesting in porting
  32. software seems to be us UNIX freaks anyway.
  33.  
  34.  
  35.  
  36.